Read Only Registry entries

Two Registry entries (added with Vitalware 2.2.01) allow all or part of the system to be read-only. The ReadOnly (System) Registry entry and ReadOnly (Table) Registry entry allow System Administrators to "turn off" record insertions and updates while still allowing the system to be operational.

Prior to Vitalware 2.2.01 it was possible to make the back-end tables read-only (and it still is), however the Vitalware client did not reflect the read-only nature of the table in the module interface: it was still possible to select the menu entry to insert a new record, but an error would then be displayed as the table was read-only. The ReadOnly Registry entries control the Vitalware client while still leaving the back-end tables operational. This means that the menu entry to insert a new record is now disabled if the table or system is marked as read-only.

The system wide read-only entry ensures that data is not modified in any modules, including the Vitalware Registry module. Some uses for this entry include:

  • Disabling data changes while the system is upgraded.
  • Providing read-only access for certain users / groups.
  • Allowing data loads to be checked before going live.

The table specific read-only entry allows individual tables or all tables to operate in a read-only state. If a table is read-only, data insertions and modifications are not permitted. The only exception is that changes to the Vitalware Registry are permitted even if the eregistry table is set to read-only. Possible uses for this entry include:

  • Disabling data changes to a single table (as it may require maintenance).
  • Providing read-only access to a table for certain users / groups.
  • Allowing Registry based operations (e.g create a new sort) while the data is read-only.

The addition of the two ReadOnly Registry entries provides System Administrators with the ability to control access to data stored in Vitalware at a system wide and table specific basis.

The ReadOnly Registry entries work alongside existing Vitalware Registry entries. For example, if a table is designated as read / write by a ReadOnly Registry entry, a user still needs the daInsert permission to be able to create records. The ReadOnly entries do not override existing Registry entries to provide more privileges than would be the case if the entry was not set.

Specify that the entire system is read-only.

The system ReadOnly entry provides the following features:

  • Data in all modules cannot be updated or created.
  • Operations involving updates to tables are disabled, namely:
    • Creating groups (uses egroups table).
    • Manipulating the records in groups (uses egroups table).
    • Creating batch exports (uses eschedule table).
    • Running batch exports (uses eexports table).
    • Create task templates (uses etemplates table).
    • Change help contents (uses efieldhelp table).
  • Operations that update the Registry are disabled, namely the creation, modification or deletion of any resources:
    • List Settings
    • Default Values
    • Ditto Record
    • Record Recall
    • Record Template
    • Reports
    • Shortcut Settings
    • Sorts
  • Operations that update the Registry when performed, but only to record the entry selected, are not disabled, namely:
    • List Settings
    • Page View
    • Query Default Values
    • Reports
    • Shortcut Settings
    • Sorts
    • Ad-hoc Sorts

The system ReadOnly entry may be used to limit access on a group or user basis.

Usage

This Registry entry can be assigned to users, groups and system-wide:

Key User Group Key System
Key 1 User Group Key 1 System
Key 2 user group Key 2 Setting
Key 3 Setting Key 3 ReadOnly
Key 4 ReadOnly    
Value boolean Value boolean
User user Setting ReadOnly boolean
Group group Setting ReadOnly boolean
System Setting ReadOnly boolean

where:

boolean

is either true (read-only functionality is enabled) or false (read-only functionality is not enabled).

Examples

If users in group Test should not update any data, the following entry may be used:

Key Setting
Key 1 Group
Key 2 Test
Key 3 Setting
Key 4 ReadOnly
Value true

Entries may also be used in combination to achieve the desired effect. For example, if all users except those in group Admin should have read-only access, the following entries may be used:

Key Setting
Key 1 System
Key 2 Setting
Key 3 ReadOnly
Value true

 

Key Setting
Key 1 Group
Key 2 Admin
Key 3 Setting
Key 4 ReadOnly
Value false

Specify that one or more (database) tables are read-only.

Usage

Key User User Group Group Group Group
Key 1 User User Group Group Group Group
Key 2 user user group group Default Default
Key 3 Table Table Table Table Table Table
Key 4 table Default table Default table Default
Key 5 ReadOnly
Value boolean
User user Table table ReadOnly boolean
User user Table Default ReadOnly boolean
Group group Table table ReadOnly boolean
Group group Table Default ReadOnly boolean
Group Default Table table ReadOnly boolean
Group Default Table Default ReadOnly boolean

where:

boolean

is true (all operations that would result in record creation or updates in the specified table are disabled) or false (update operations are allowed, subject to other permissions, e.g. operational permissions).

The one exception to the rule is the Registry table (eregistry). If the Registry is made read-only, only explicit changes, that is changes made from the Registry module, are disabled. All implicit changes (e.g. adding a new sort definition) are still permitted. Hence the creation, modification or deletion of any resources is permitted, namely:

  • List Settings
  • Default Values
  • Ditto Record
  • Record Recall
  • Record Template
  • Reports
  • Shortcut Settings
  • Sorts

Using the first form of the table ReadOnly Registry entry:

Group Default Table Default ReadOnly true

disables data creation and updates in all tables while still permitting most operational commands (e.g. report creation). When compared with the system ReadOnly setting, the table setting restricts only data modifications, rather than data and operational functionality.

User / group based variants of the table Registry entry may be used to restrict access to a select number of individuals. For example, if users in group QA are not allowed to create or modify records in the registration modules, the following Registry entry may be used:

Group QA Table ebirths ReadOnly true

As with the system ReadOnly entry, table based entries may be combined to produce the desired effect. For example, if users in group QA were only allowed to update the egroups, eschedule and eexports tables (allowing them to create groups and batch exports), then the following Registry entries may be used:

Group QA Table Default ReadOnly true
Group QA Table egroups ReadOnly false
Group QA Table eschedule ReadOnly false
Group QA Table eexports ReadOnly false

Example 1

Your Vitalware installation is to be upgraded to the next release of the software. While the upgrade is proceeding you would like users to be able to view data in the live system, but not make any changes as they will be lost when the upgraded system replaces the live system. The following Registry entry may be used:

System Setting ReadOnly true

This setting will disable all Vitalware functions that would result in any data changes. Users may still produce reports, sort records, etc., however data changes are not allowed.

Example 2

You have received an initial data load in Vitalware ready for checking. You do not want users to modify any data as they are only determining the integrity of the load. In order to make the reporting of issues easier, you would like users to be able to create groups so they can group records where the data does not look correct. The following Registry entries may be used:

Group Default Table Default ReadOnly true
Group Default Table egroups ReadOnly false

The disabling of the read-only status on egroups allows users to create and manipulate groups.

Example 3

You have created a duplicate version of your live system for access via the web. You do not want users to be able to alter any data in the web copy, however all other functionality should be available. The following Registry entries may be used:

Group Default Table Default ReadOnly true
Group Default Table egroups ReadOnly false
Group Default Table eschedule ReadOnly false
Group Default Table eexports ReadOnly false
Group Default Table etemplates ReadOnly false
Group Default Table efieldhelp ReadOnly false

The enabling of read / write access to the egroups, eschedule, eexports, etemplates and efieldhelp tables will allow full command functionality on a read-only system. You may want to exclude some of these tables if you want to further limit functionality. For example, removing efieldhelp will disable the updating of field level help.

Example 4

You are undertaking a clean up of the Lookup List table (eluts) so you would like to limit the update of Lookup Lists to users in group Admin. The following Registry entries may be used:

Group Default Table eluts ReadOnly true
Group Admin Table eluts ReadOnly false

When the eluts table is read-only, users may not insert new values into the table. This means all lookup lists are treated as read-only. Users may find this annoying as it may make it difficult to save records.

Example 5

You have just received an allocation of staff to add field level help for all modules in the system. You do not want the staff to alter any other data apart from field level help. You have created a group called Volunteers and placed the allocated staff in the group. The following Registry entries may be used:

Group Volunteers Table Default ReadOnly true
Group Volunteers Table efieldhelp ReadOnly false

In order for the volunteers to be able to create the field level help for all modules, you would also need to assign the daEditHelp permission for group Volunteers.

In general, it is not wise to mix System based and Table based ReadOnly Registry entries. Consider the following settings:

Group QA Setting ReadOnly true
Group QA Table eparties ReadOnly false

Which entry takes precedence? Can users in group QA write to the eparties table? The current implementation gives priority to the system entries over table based entries. So for the example above, users in group QA would not be able to write to the Parties module.